YC와 Palantir가 말하는 FDE
FDE는 직무이기도 하지만 제품 전략이기도 하다. Palantir에서 왜 이 전략이 생겨야 했고, 왜 한동안 "특이한 회사의 특이한 방식" 취급을 받았으며, 왜 2024~2025년에 갑자기 AI 스타트업 전체가 이걸 따라 하기 시작했는지 알아보자.
Y Combinator에서 Bob McGrew(Palantir 초기 임원, 전 OpenAI CRO)가 한 시간 가까이 풀어놓은 이야기가 이 흐름을 가장 잘 설명한다.
정석 루트를 못 탄 회사
제품을 만들고 시장에 내놓는 정석 이론은 비교적 깔끔하다. 고객과 부딪히며 제품-마켓핏을 찾고, 일단 찾으면 고객과 거리를 둔다. 모든 고객을 동일하게 취급하고, 스케일링에 집중한다. Crossing the Chasm 같은 고전이 말하는 흐름이다.
McGrew는 대놓고 말한다. "이 루트가 되면 그냥 그렇게 하세요. 굳이 FDE 전략을 쓸 이유가 없습니다."
Palantir는 그게 안 됐다. 정보기관용 소프트웨어를 만들었는데, 일단 스파이를 아는 사람이 없었다. 스파이한테 "뭐 하시는 분이세요?" 물어도 안 알려준다. 그래서 데모를 만들어 가져갔더니 고객이 "이건 우리 일과 전혀 상관없다"고 했다. 그 자리에서 피드백을 받아 고치고, 다시 가져가고를 반복했다. 여기까진 YC가 늘 하는 조언("do things that don't scale")과 비슷하다.
다른 점은 그다음이다. 첫 고객에서 맞춘 제품을 다음 고객에 가져가면, 필요한 게 미묘하게 달랐다. 대테러 워크플로와 대확산(핵무기) 워크플로는 비슷해 보여도 실제로는 꽤 다르다. 세그먼트마다 제품을 따로 만들 수도 없고, 하나로 억지로 끼워 맞추면 아무 데도 안 맞는다.
비포장도로와 고속도로
여기서 Sham Sankar(현 Palantir CTO)가 뒤집은 관점이 있다. 현장에 사람을 보내는 건 보통 '서비스 비용'으로 취급된다. 줄여야 할 것. Sankar는 이걸 '제품 발견 장치'로 바꿨다.
FDE가 고객 현장에 가서 그 고객만의 문제를 빠르게 푼다. 이건 비포장도로다. 거칠고 한 고객 전용이다. 본사 제품 팀은 이 비포장도로를 보고 "이걸 다음 5~10개 고객에도 통하게 하려면 어떤 형태여야 하나"를 판단한다. 그걸 포장된 고속도로로 만든다.
McGrew의 표현으로는 "doing things that don't scale at scale", 비확장적인 일을 반복 가능하게 하는 것이다.
여기에 핵심 실패 모드가 하나 있다. FDE가 한 고객을 위해 만든 것을 그대로 제품에 넣는 것. 그러면 다른 고객에게는 과잉 특화된 기능이 된다. 제품 팀의 역할은 현장의 구체적 문제에서 한 단계 더 일반적인 문제를 뽑아내는 것이다. McGrew는 Palantir가 오래 PM을 안 뽑았고, 나중에 뽑을 때도 다른 회사 출신 PM들이 이 추상화를 잘 못 했다고 한다. 그들은 "이 고객의 이 플로를 이렇게 만들자"는 답을 내놨는데, 필요한 건 "이 속성을 가진 모든 것에 이 연산을 적용할 수 있게 하자"였다. Palantir의 유명한 온톨로지 구조가 이 사고에서 나왔다.
FDE와 제품 팀 사이의 긴장
비포장도로를 깐 사람과 고속도로를 만드는 사람 사이에 갈등이 없을 리 없다.
FDE는 현장에 있고, 지금 이 고객의 문제를 가장 단순한 방법으로 푸는 게 합리적이다. 제품 팀은 여러 고객에 걸쳐 작동하는 일반화를 만들어야 한다. 인센티브가 다르니까 마찰이 생긴다.
McGrew는 이걸 '스킬 차이'보다 '인센티브 차이'라고 짚었다. 재밌는 건 FDE가 현장을 오래 경험한 뒤 본사 제품 팀으로 오면 오히려 그 추상화를 잘하는 경우가 많았다는 것이다. 환경이 바뀌면 사고도 바뀐다.
해결법은 여러 고객의 FDE를 같은 테이블에 앉히는 것이었다. A 고객에서 프로토타입한 기능을 B, C 고객 FDE와 함께 보면, 세 가지 미묘하게 다른 워크플로가 눈에 보인다. 그러면 "일반화 vs 특화" 싸움이 아니라 같은 문제를 다 같이 푸는 그림이 된다.
컨설팅 회사가 되는 리스크
"그냥 컨설팅 아니냐"는 FDE에 붙는 가장 흔한 의심이다. McGrew는 이 질문에 "솔직히 그 위험은 진짜 있다"고 시작한다. 2015년경 Palantir에 대해 사람들이 두 가지를 말했다. 하나는 "Palantir는 악하다", 다른 하나는 "스케일 안 되는 컨설팅 사업이다."
비즈니스 모델 관점에서 구분되는 지점은 시간축이다. 새 고객에 투입할 때는 마진이 마이너스일 수 있다. 시간이 지나면 두 가지가 일어난다.
- 제품이 고객 업무에 더 맞아가면서, 현장에 붙여야 하는 사람 수가 줄어든다.
- 첫 문제를 풀면서 신뢰를 쌓으면, 더 크고 가치 있는 문제에 접근할 권한이 생긴다.
결과적으로 고객당 비용 대비 납부 가치가 점점 올라가야 한다. 마진이 처음엔 음수였다가 1년, 어쩌면 몇 년 뒤 양수로 넘어가는 구조. 이게 안 되면 진짜 컨설팅이다. 되면 플랫폼 비즈니스의 다른 형태다.
또 하나 더 빠지기 쉬운 함정이 있다. 고객이 요청하는 것을 만드는 게 아니라, 고객에게 진짜 가치 있는 것을 만들어야 한다는 것. 고객은 하나의 개인이 아니라 조직이다. 미팅에 나오는 CIO나 중간 스폰서가 원하는 건, 자기가 시키기 쉬운 일이지 반드시 사업에 임팩트 있는 일은 아니다. CEO의 상위 5개 우선순위에 해당하지 않는 문제를 풀면, 조직적 지원도 약하고 결국 성과도 흐지부지된다.
AI 에이전트 시장에서 FDE가 다시 뜬 이유
McGrew는 FDE 전략을 권유하냐는 질문에 "첫째도 하지 마세요, 둘째도 하지 마세요, 셋째도 하지 마세요"라고 답한다. 피할 수 있으면 피하라는 건데, 피할 수 없어서 할 수밖에 없고, 그 자체가 해자가 되면 그때야 해볼 만하다는 뜻이다.
그럼 왜 AI 에이전트 시장은 이걸 피할 수 없는가. 핵심은 기존 인컴번트 제품이 없다는 것이다.
SaaS라면 이미 돌아가는 청구 시스템이 있고, 그걸 더 나은 청구 시스템으로 교체하는 게 게임이다. 시장이 뭔지 다 안다. 세그먼트가 크게 갈라지지 않는다. 마켓핏 한 번 맞추면 스케일 타면 된다.
AI 에이전트는 다르다. 시장 자체가 아직 정의되지 않았다. McGrew는 "5년 뒤 돌아보면 'AI 에이전트'라는 건 하나의 것이 아니었다는 걸 알게 될 것"이라고 한다. 실제로는 완전히 다른 여러 가지 일이었는데, 지금은 다 같은 이름을 붙이고 있을 뿐이다.
Palantir도 비슷했다. 정보기관, 법 집행, 군, 상업 금융 등 각 세그먼트가 비슷해 보이면서도 실제 워크플로는 꽤 달랐다. 한 세그먼트 안에서는 제품-마켓핏이 어느 정도 적용되지만, 다음 세그먼트로 넘어가면 또 새로운 기술이 필요했다.
AI 에이전트 시장이 같은 상태다. 발견해야 할 것이 너무 많고, 그 발견은 기업 현장 안에서만 할 수 있다.
SaaS 전략과 FDE 전략의 갈림
McGrew가 정리한 두 전략의 차이는 깔끔하다.
SaaS/제품-마켓핏 전략
고객당 커스텀 작업을 줄이고, 계약 규모는 유지하면서, 마진을 올린다.
FDE 전략
계약 규모를 키운다. 더 가치 있는 문제를 풀고, 그래서 더 큰 계약을 받는다. 고객당 커스텀 양은 줄지 않아도 된다. 대신 같은 커스텀 양으로 더 큰 가치를 뽑으면 된다.
측정 지표도 다르다. SaaS는 고객당 비용을 줄이는 게 핵심이고, FDE 쪽은 두 가지를 본다.
- 고객에게 전달하는 결과의 가치가 올라가고 있는가
- 같은 결과를 내는 데 제품 레버리지가 늘고 있는가 (FDE 5명이 하던 걸 2명이 할 수 있게 되는가)
첫 번째가 올라가면 사업이 작동하는 것이고, 두 번째가 올라가면 플랫폼이 학습하고 있는 것이다.
데모 주도 개발
Palantir 초기에는 데모가 하나뿐이었다. 테러 음모를 저지하는 시나리오다. 새 기능이 추가될 때마다 이 데모 안에서 그 기능이 왜 필요한지를 보여줘야 했다. 히스토그램을 넣으면 "분석가가 이 음모를 추적하는 과정에서 히스토그램이 왜 도움이 되는가?"를 데모에 녹여야 했다.
이게 제품 사고를 강제한다. 엔지니어 관점에서는 기능 단위로 생각하기 쉽다. 이 기능이 기술적으로 좋은가. 데모 관점에서는 고객 입장이 된다. 이 기능이 내 일에 실제로 끼어들어야 하는가. 보여줬을 때 고객이 손 뻗어서 가져가고 싶어 하는가.
McGrew는 고객에게 데모를 보여줬을 때 "그걸 자기 일에 가져다 쓰고 싶다는 욕구"가 보이면 진짜 문제를 건드린 것이라고 한다. 안 보이면 잘못 짚은 것이다.
어디서 틀리는가
McGrew가 FDE 전략을 시도하는 AI 스타트업들에서 보는 실수를 정리하면 대략 이렇다.
Palantir 출신 없이 세컨드핸드로 돌리는 경우. 엔지니어링은 일반 SWE와 비슷할 수 있지만, 계정을 어떻게 키우고 고객 내부에서 결과를 어떻게 찾는지는 해본 사람이 가르치는 게 빠르다고 한다.
결과가 아니라 소프트웨어 설치를 파는 경우. FDE 모델에서 파는 것은 "문제를 풀어드렸다"는 결과이지, 소프트웨어 라이선스가 아니다. 가격 책정도 시트 수나 사용량 기반이 아니라 결과의 가치에 묶인다. SaaS 습관이 남아 있으면 이 전환이 어렵다.
조직 내 관문을 과소평가하는 경우. CEO의 상위 5대 우선순위가 아닌 문제를 풀면, IT 부서의 보안 심사, 데이터 거버넌스, 온프레미스 인프라 요건 같은 장벽을 넘을 정치적 힘이 없다. 위에서 "저 팀에 권한 줘라"고 내려와야 하는데, 그러려면 충분히 중요한 문제여야 한다.
능력은 빠르게 오르지만 도입은 느리다
McGrew가 마지막에 한 말이 인상 깊다. GPT-4o에서 o3까지 1년 사이에 능력은 엄청나게 올라갔고, 앞으로도 계속 올라갈 것이다. 그런데 실제 도입은 능력의 속도를 전혀 따라가지 못한다. 자율 택시를 타면서도 "신기하다"가 아니라 "아 막히네"라고 생각하게 되는 식으로, 세상은 놀랍도록 평범하게 느껴질 거라고.
이게 기회다. 모델이 할 수 있는 것과 사람이 실제로 쓰고 있는 것 사이의 간격이 계속 벌어진다. 그 간격을 메우는 일은 기술만으로 안 되고, 현장에서 사람의 탐색과 고통이 필요하다. FDE 전략이 다시 뜬 건 그 간격이 AI 분야에서 유독 크기 때문이다.
YC 호스트는 이렇게 비유했다. "OpenAI가 본사 제품 팀이고, AI 스타트업들이 FDE 역할을 하는 것 아닌가." McGrew는 "꽤 맞는 비유"라고 답했다.